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Abstract 



We discuss abstractions for protection and the correctness of their imple- 
mentations. Relying on the concept of full abstraction, we consider two 
examples: (1) the translation of Java classes to an intermediate bytecode 
language, and (2) in the setting of the pi calculus, the implementation of 
private channels in terms of cryptographic operations. 
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1 Introduction 



Tangible crimes and measures against those crimes are sometimes explained 
through abstract models — with mixed results, as the detective Erik Lonnrot 
discovered [Bor74]. Protection in computer systems relies on abstractions 
too. For example, an access matrix is a high-level specification that de- 
scribes the allowed accesses of subjects to objects in a computer system; 
the system may rely on mechanisms such as access lists and capabilities for 
implementing an access matrix [LamTl]. 

Abstractions are often embodied in programming-language constructs. 
Recent work on Java [GJS96] has popularized the idea that languages are 
relevant to security, but the relation between languages and security is much 
older. In particular, objects and types have long been used for protection 
against incompetence and malice, at least since the 1970s [Mor73, LS76, 
JL78]. In the realm of distributed systems, programming languages (or their 
libraries) have sometimes provided abstractions for communication on se- 
cure channels of the kind implemented with cryptography [Bir85, WABL94, 
VDABW96, WRW96, Sun97b]. 

Security depends not only on the design of clear and expressive abstrac- 
tions but also on the correctness of their implementations. Unfortunately, 
the criteria for correctness are rarely stated precisely — and presumably they 
are rarely met. These criteria seem particularly delicate when a principal 
relies on those abstractions but interacts with other principals at a lower 
level. For example, the principal may express its programs and policies in 
terms of objects and remote method invocations, but may send and receive 
bit strings. Moreover, the bit strings that it receives may not have been the 
output of software trusted to respect the abstractions. Such situations seem 
to be more common now than in the 1970s. 

One of the difficulties in the correct implementation of secure systems is 
that the standard notion of refinement (e.g., [Hoa72, Lam89]) docs not pre- 
serve security properties. Ordinarily, the non-determinism of a specification 
may be intended to allow a variety of implementations. In security, the non- 
determinism may also serve for hiding sensitive data. As an example, let us 
consider a specification that describes a computer that displays an arbitrary 
but fixed string in a corner of a screen. A proposed implementation might 
always display a user's password as that string. Although this implementa- 
tion may be functionally correct, we may consider it incorrect for security 
purposes, because it leaks more information than the specification seems to 
allow. Security properties are thus different from other common properties; 
in fact, it has been argued that security properties do not conform to the 
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Alpern- Schneider definition of properties [AS85, McL96]. 

Reexamining this example, let us write P for the user's password, I{P) 
for the proposed implementation, and S{P) for the specification. Since the 
set of behaviors allowed by the specification does not depend on P, clearly 
S{P) is equivalent to S{P') for any other password P'. On the other hand, 
J(P) and I{P') are not equivalent, since an observer can distinguish them. 
Since the mapping from specification to implementation does not preserve 
equivalence, we may say that it is not fully abstract [Plo77]. We may explain 
the perceived weakness of the proposed implementation by this failure of full 
abstraction. 

This paper suggests that, more generally, the concept of full abstraction 
is a useful tool for understanding the problem of implementing secure sys- 
tems. Pull abstraction seems particularly pertinent in systems that rely on 
translations between languages — for example, higher-level languages with 
objects and secure channels, lower-level languages with memory addresses 
and cryptographic keys. 

We consider two examples of rather different natures and review some 
standard security concerns, relating these concerns to the pursuit of full 
abstraction. The first example arises in the context of Java (section 2). The 
second one concerns the implementation of secure channels, and relies on 
the pi calculus as formal framework (section 3). The thesis of this paper 
about full abstraction is in part a device for discussing these two examples. 

This paper is rather informal and partly tutorial; its contributions are 
a perspective on some security problems and some examples, not new theo- 
rems. Related results appear in more technical papers [SA98, AFG98]. 

Full abstraction, revisited 

We say that two expressions are equivalent in a given language if they yield 
the same observable results in all contexts of the language. A translation 
from a language Li to a language L2 is equationally fully abstract if (1) it 
maps equivalent Li expressions to equivalent L2 expressions, and (2) con- 
versely, it maps nonequivalent Li expressions to nonequivalent L2 expres- 
sions [Plo77, Sha91, Mit93]. We may think of the context of an expression as 
an attacker that interacts with the expression, perhaps trying to learn some 
sensitive information (e.g., [AG97a]). With this view, condition (1) means 
that the translation does not introduce information leaks. Since equations 
may express not only secrecy properties but also some integrity properties, 
the translation must preserve those properties as well. Because of these con- 
sequences of condition (1), we focus on it; we mostly ignore condition (2), 
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although it can be useful too, in particular for excluding trivial translations. 

Closely related to equational full abstraction is logical full abstraction. 
A translation from a language Li to a language L2 is logically fully abstract 
if it preserves logical properties of the expressions being translated [LP98]. 
Longley and Plotkin have identified conditions under which equational and 
logical full abstraction are equivalent. Since we use the concept of full ab- 
straction loosely, we do not distinguish its nuances. 

An expression of the source language Li may be written in a silly, in- 
competent, or even malicious way. For example, the expression may be a 
program that broadcasts some sensitive information — so this expression is 
insecure on its own, even before any translation to -L2. Thus, full abstraction 
is clearly not sufficient for security; however, as we discuss in this paper, it 
is often relevant. 

2 Objects and Mobile Code 

The Java programming language is typically compiled to an intermediate 
language, which we call JVML and which is implemented by the Java Virtual 
Machine [GJS96, LY96]. JVML programs are often communicated across 
networks, for example from Web servers to their clients. A client may run 
a JVML program in a Java Virtual Machine embedded in a Web browser. 
The Java Virtual Machine helps protect local resources from mobile JVML 
programs while allowing those programs to interact with local class libraries. 
Some of these local class libraries perform essential functions (for example, 
input and output), so they are often viewed as part of the Java Virtual 
Machine. 

2.1 Translating Java to JVML 

As a first example we consider the following trivial Java class: 

cIeiss C { 

private int x; 
public void set x (int v) { 
this.x = v; 

}; 

} 

This class describes objects with a field x and a method set_x. The method 
set_x takes an integer argument v and updates the field x to v. The keyword 
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this represents the self of an object; the keyword public indicates that any 
client or subclass can access set_x directly; the keyword private disallows 
a similar direct access to x from outside the class. Therefore, the field x can 
be written but never read. 

The result of compiling this class to JVML may be expressed roughly as 
follows. (Here we do not use the official, concrete syntax of JVML, which is 
not designed for human understanding.) 

class C { 

private int x; 

public void set x (int) { 

.f ramelimits locals = 2, stack = 2; 



As this example indicates, JVML is a fairly high-level language, and in 
particular it features object-oriented constructs such as classes, methods, 
and self. It differs from Java in that methods manipulate local variables, 
a stack, and a heap using low-level load and store operations. The details 
of those operations are not important for our purposes. Each method body 
declares how many local variables and stack slots its activation may require. 
The Java Virtual Machine includes a bytccode verifier, which checks that 
those declarations are conservative (for instance, that the stack will not 
overflow). If undetected, dynamic errors such as stack overflow could lead 
to unpredictable behavior and to security breaches. 

The writer of a Java program may have some security-related expec- 
tations about the program. In our simple example, the field x cannot be 
read from outside the class, so it may be used for storing sensitive informa- 
tion. Our example is so trivial that this information cannot be exploited 
in any way, but there are more substantial and interesting examples that 
permit controlled access to fields with the qualifier private and similar 
qualifiers. For instance, a Java class for random-number generation (like 
java.util .Random) may store seeds in private fields. In these examples, a 
security property of a Java class may be deduced — or presumed — by con- 
sidering all possible Java contexts in which the class can be used. Because 
those contexts must obey the type rules of Java, they cannot access private 
fields of the class. 



aload.O ; 
iload.l ; 
putfield x; 



// load this 
// load V 
// set X 



} 
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When a Java class is translated to JVML, one would like the resulting 
JVML code to have the security properties that were expected at the Java 
level. However, the JVML code interacts with a JVML context, not with a 
Java context. If the translation from Java to JVML is fully abstract, then 
matters are considerably simplified — in that case, JVML contexts have no 
more power than Java contexts. Unfortunately, as we point out below, the 
current translation is not fully abstract (at least not in a straightforward 
sense). Nevertheless, the translation approximates full abstraction: 

• In our example, the translation retains the qualifier private for x. The 
occurrence of this qualifier at the JVML level may not be surprising, 
but it cannot be taken for granted. (At the JVML level, the qualifier 
does not have the benefit of helping programmers adhere to sound 
software-engineering practices, since programmers hardly ever write 
JVML, so the qualifier might have been omitted.) 

• Furthermore, the bytecodc verifier can perform standard typechecking, 
guaranteeing in particular that a JVML class does not refer to a private 
field of another JVML class. 

• The bytecode verifier can also check that dynamic errors such as stack 
overflow will not occur. Therefore, the behavior of JVML classes 

should conform to the intended JVML semantics; JVML code can- 
not get around the JVML type system for accessing a private field 
inappropriately. 

Thus, the bytecode verifier restricts the set of JVML contexts, and in ef- 
fect makes them resemble Java contexts (cf. [GJS96, p. 220]). As the set 
of JVML contexts decreases, the set of equivalences satisfied by JVML pro- 
grams increases, so the translation from Java to JVML gets closer to full 
abstraction. Therefore, we might even view full abstraction as the goal of 
bytecode verification. 

Recently, there have been several rigorous studies of the Java Virtual Ma- 
chine, and in particular of the bytecode verifier [Coh97, SA98, Qia97, FM98]. 
These studies focus on the type-safety of the JVML programs accepted by 
the bytecode verifier. As has long been believed, and as Leroy and Rouaix 
have recently proved in a somewhat different context [LR98] , strong typing 
yields some basic but important security guarantees. However, those guaran- 
tees do not concern language translations. By themselves, those guarantees 
do not imply that libraries written in a high-level language have expected 
security properties when they interact with lower-level mobile code. 
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2.2 Obstacles to full abstraction 



As noted, the current translation of Java to JVML is not fully abstract. The 
following variant of our first example illustrates the failure of full abstraction. 
We have no reason to believe that it illustrates the only reason for the 
failure of full abstraction, or the most worrisome one; Dean, Felten, Wallach, 
and Balfanz have discovered several significant discrepancies between the 
semantics of Java and that of JVML [DFWB98]. 

cIeiss D { 

class E { 

private int y = x; 

}; 

private int x; 
public void set _x (int v) { 
this.x = v; 

}; 

} 

The class E is an inner class [Sun97a]. To each instance of an inner class 
such as E corresponds an instance of its outer class, D in this example. The 
inner class may legally refer to the private fields of the outer class. 

Unlike Java, JVML does not include an inner-class construct. Therefore, 
compilers "flatten" inner classes while adding accessor methods. Basically, 
as far as compilation is concerned, we may as well have written the following 
classes instead of D: 

class D { 

private int x; 
public void set _x (int v) { 
this.x = v; 

}; 

static int get_x(D d) { 
return d.x; 

} 

cIeiss E { 

. . . get X . . . 

} 

Here E is moved to the top level. A method get_x is added to D and used in 
E for reading x; the details of E do not matter for our purposes. The method 
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get_x can be used not just in E, however — any other class within the same 
package may refer to get_x. 

When the classes D and E are compiled to JVML, therefore, a JVML 
context may be able to read x in a way that was not possible at the Java 
level. This possibility results in the loss of full abstraction, since there is 
a JVML context that distinguishes objects that could not be distinguished 
by any Java context. More precisely, a JVML context that runs get_x and 
returns the result distinguishes instances of D with different values for x. 

This loss of full abstraction may result in the leak of some sensitive 
information, if any was stored in the field x. The leak of the contents of a 
private component of an object can be a concern when the object is part of 
the Java Virtual Machine, or when it is trusted by the Java Virtual Machine 
(for example, because a trusted principal digitally signed the object's class). 
On the other hand, when the object is part of an applet, this leak should 
not be surprising: applets cannot usually be protected from their execution 
environments. 

For better or for worse, the Java security story is more complicated and 
dynamic than the discussion above might suggest. In addition to protection 
by the qualifier private, Java has a default mode of protection that protects 
classes in one package against classes in other packages. At the language 
level, this mode of protection is void — any class can claim to belong to any 
package. However, Java class loaders can treat certain packages in special 
ways, guaranteeing that only trusted classes belong to them. Our example 
with inner classes does not pose a security problem as long as D and E are 
in one of those packages. 

In hindsight, it is not clear whether one should base any security expecta- 
tions on qualifiers like private, and more generally on other Java constructs. 
As Dean et al. have argued [DFWB98], the definition of Java is weaker than 
it should be from a security viewpoint. Although it would be prudent to 
strengthen that definition, a full-blown requirement of full abstraction may 
not be a necessary addition. More modest additions may suffice. Section 4 
discusses this subject further. 

3 Channels for Distributed Communication 

In this section, we consider the problem of implementing secure channels 
in distributed systems. As mentioned in the introduction, some systems 
for distributed programming offer abstractions for creating and using secure 
channels. The implementations of those channels typically rely on cryptog- 
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raphy for ensuring the privacy and the integrity of network communication. 
The relation between the abstractions and their implementations is usually 
explained only informally. Moreover, the abstractions are seldom explained 
in a self-contained manner that would permit reasoning about them without 
considering their implementations at least occasionally. 

The concept of full abstraction can serve as a guide in understanding se- 
cure channels. When trying to approximate full abstraction, we rediscover 
common attacks and countermeasures. Most importantly, the pursuit of full 
abstraction entails a healthy attention to the connections between an imple- 
mentation and higher-level programs that use the implementation, beyond 
the intrinsic properties of the implementation. 



3.1 Translating the pi calculus to the spi calculus 

The formal setting for this section is the pi calculus [Mil92, MPW92, Mil93], 
which serves as a core calculus with primitives for creating and using chan- 
nels. By applying the pi calculus restriction operator, these channels can 
be made private. We discuss the problem of mapping the pi calculus to a 
lower- level calculus, the spi calculus [AG97b, AG97c, AG97a], implementing 
communication on private channels by encrypted communication on public 
channels. Several low-level attacks can be cast as counterexamples to the full 
abstraction of this mapping. Some of the attacks can be thwarted through 
techniques common in the literature on protocol design [MvOV96]. Some 
other attacks suggest fundamental difficulties in achieving full abstraction 
for the pi calculus. 

First we briefly review the spi calculus. In the variant that we consider 
here, the syntax of this calculus assumes an infinite set of names and an 
infinite set of variables. We let c, d, m, n, and p range over names, and let 
w, X, y, and z range over variables. We usually assume that all these names 
and variables arc different (for example, that m and n are different names). 
The set of terms of the spi calculus is defined by the following grammar: 

L,M,N::= terms 
n name 
X variable 
{Ml ,...,Mk}N encryption ( A; > 0) 

Intuitively, {Mi , . . . , Mk}N represents the ciphertext obtained by encrypting 
the terms Mi , . . . , M^ under the key N (using a symmetric cryptosystem 
such as DES or RC5 [MvOV96]). The set of processes of the spi calculus is 
defined by the following grammar: 
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P,Q::= 



processes 



M{Ni,...,Nk) 

M{xi,...,Xk).P 

0 



output (fc > 0) 
input (fc > 0) 
nil 

composition 
replication 
restriction 
match 

decryption (fc > 0) 



P\Q 



\P 

{m)P 
[M is N] P 

case L of {xi, . . . , Xk}N in P 



An output process M{Ni, . . . , N^) sends the tuple A''i, . . . , on M. An in- 
put process M{xi, . . . , Xk)-Q is ready to input k terms Ni, . . . ,N^.on M, and 
then to behave as Q[Ni/xi, . . . , Nk/xk\- Here we write Q[Ni/xi, . . . , Nk/xk] 
for the result of replacing each free occurrence of Xi in Q with Ni, for i G l..k. 
Both M{xi, . . . , Xk)-Q and case L of {xi, . . . , Xfcjiv in P (explained below) 
bind the variables xi, . . . , Xk- The nil process 0 does nothing. A composi- 
tion P I Q behaves as P and Q running in parallel. A replication IP behaves 
as infinitely many copies of P running in parallel. A restriction (z^n)P makes 
a new name n and then behaves as P; it binds the name n. A match process 
[M is N] P behaves as P if M and N are equal; otherwise it does nothing. 
A decryption process case L of {xi, . . . ,Xk}N in. P attempts to decrypt L 
with the key N; if L has the form {Mi, . . . , M^} jv, then the process behaves 
as P[Mi/xi, . . . , Mk/xk]; otherwise it does nothing. 

By omitting the constructs {Mi, . . . , M^} n and case L of {xi, . . . , Xk}N 
in P from these grammars, we obtain the syntax of the pi calculus (more 
precisely, of a polyadic, asynchronous version of the pi calculus). 

As a first example, we consider the trivial pi calculus process: 



This is a process that creates a channel n, then uses it for transmitting the 
name m, with no further consequence. Communication on n is secure in 
the sense that no context can discover m by interacting with this process, 
and no context can cause a different message to be sent on n; these are 
typical secrecy and integrity properties. Such properties can be expressed as 
equivalences (in particular, as testing equivalences [DH84, BN95, AG97a]). 
For example, we may express the secrecy of m as the equivalence between 
{vn)in{m) \ n[x).0) and {un){n{m') \ n{x).0), for any names m and m' . 

Intuitively, the subprocesses n(m) and n{x).0 may execute on differ- 
ent machines; the network between these machines may not be physically 



{un){n{m) \ n{x).0) 
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secure. Therefore, we would like to explicate a channel like n in lower- 
level terms, mapping it to some sort of encrypted connection multiplexed 
on a public channel. For example, we might translate our first process, 
{i"n){n{m.) \ n(x).O), into the following spi calculus process: 

{un){c{{m}n) I c{y).case y of {x}n in 0) 

Here c is a distinguished, free name, intuitively the name of a well-known 
public channel. The name n still appears, with a restriction, but it is used 
for a key rather than for a channel. The sender encrypts m using n; the 
recipient tries to decrypt a ciphertext y that it receives on c using n; if the 
decryption succeeds, the recipient obtains a cleartext x (hopefully m). 

This translation strategy may seem promising. However, it has numerous 
weaknesses; wc describe several of those weaknesses in what follows. The 
weaknesses represent obstacles to full abstraction and are also significant in 
practical terms. 

3.2 Obstacles to full abstraction 
Leak of traffic patterns 

In the pi calculus, (i/n)(n(m) | n(x).O) is simply equivalent to 0, because 
the internal communication on n cannot be observed. On the other hand, in 
the spi calculus, (z/ra)(c({m}„) | c{y).case y of {x}n in 0) is not equivalent 
to the obvious implementation of 0, namely 0. A spi calculus process that 
interacts with {un){c{{m}n) \ c{y).case y of {x}n in, 0) can detect traffic on 
c, even if it cannot decrypt that traffic. 

The obvious way to protect against this leak is to add noise to communi- 
cation lines. In the context of the spi calculus, we may for example compose 
all our implementations with the noise process \{iyp)c{{}p). This process con- 
tinually generates keys and uses those keys for producing encrypted traffic 
on the public channel c. 

In practice, since noise is rather wasteful of communication resources, 
and since a certain amount of noise might be assumed to exist on commu- 
nication lines as a matter of course, noise is not always added in implemen- 
tations. Without noise, full abstraction fails. 

Trivial denial-of-service vulnerability 

Consider the pi calculus process 

{i'n){n{m) \ n{x).x{)) 
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which is a small variant of the first example where, after its receipt, the 
message m is used for sending an empty message. This process preserves 
the integrity of m, in the sense that no other name can be received and used 
instead of m; therefore, this process is equivalent to rn{). 

The obvious spi calculus implementations of {un){n{m) \ n{x).x{)) and 
m() are respectively 

{iyn){c{{m}n) \ c{y).case y of {x}n in c{{}x)) 

and c({}m). These implementations can be distinguished not only by traffic 
analysis but also in other trivial ways. For example, the former implementa- 
tion may become stuck when it interacts with c{p) , because the decryption 
case y of {x}n in c{{}x) fails when y is p rather than a ciphertext. In 
contrast, the latter implementation does not suffer from this problem. 

Informally, we may say that the process c{p) mounts a denial-of-service 
attack. Formally, such attacks can sometimes be ignored by focusing on pro- 
cess equivalences that capture only safety properties, and not liveness prop- 
erties. In addition, the implementations may be strengthened, as is com- 
monly done in practical systems. For example, as a first improvement, we 
may add some replication to (i/n)(c({m}„) | c{y).case y of {x}„ in c{{}x)), 
obtaining: 

{i^n){c{{m}n) I \c{y).case y of {x}n in c{{}x)) 
This use of replication protects against c{p). 



Exposure to replay attacks 



Another shortcoming of our implementation strategy is exposure to replay 
attacks. As an example, we consider the pi calculus process: 

[vn)in{mi) \ n{m2) \ n{x).x{) j n{x).x{)) 

which differs from the previous example only in that two names mi and 
m2 are transmitted on n, asynchronously. In the pi calculus, this process is 
equivalent to mi() | frvzQ: it is guaranteed that both mi and m2 go from 
sender to receiver exactly once. 

This guarantee is not shared by the spi calculus implementation 



(un) 



' c({mi}n) I c({m2}n) I ^ 

c{y).case y of {x}„ in c({}^) | 
y c{y).case y of {x}n in c{{}x) J 
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independently of any denial-of-service attacks. When this implementation 
is combined with the spi calculus process c{y).{c{y) \ c{y)), which duplicates 
a message on c, two identical messages may result, either c{{}mi) | c({}mi) 
or c{{}m2) I c({} 

m2/- 

Informally, we may say that the process c{y).{c{y) \ c{y)) mounts a replay 
attack. Standard countermeasures apply: timestamps, sequence numbers, 
and challenge-response protocols. In this example, the addition of a minimal 
challenge-response protocol leads to the following spi calculus process: 



' c(2:i).c({mi, I c(z2).c({m2,2:2}n) I ^ 

(z/pi)(c(pi) I c{y).case y of {x,zi}n in {z\ is pi] c({}a;)) | 
\ (z^P2)(c(]92) I c{y).case y of {x,Z2}n in [z2 is P2] c{{}x)) J 



The names pi and p2 serve as challenges; they are sent by the subpro- 
cesses that are meant to receive mi and m2, received by the subprocesses 
that send mi and m2, and included along with mi and m2 under n. This 
challenge-response protocol is rather simplistic in that the challenges may 
get "crossed" and then neither mi nor m2 would be transmitted successfully; 
it is a simple matter of programming to protect against this confusion. In 
any case, for each challenge, at most one message is accepted under n. This 
use of challenges thwarts replay attacks. 

Leak of message equalities 

In the pi calculus, the identity of messages sent on private channels is con- 
cealed. For example, an observer of the process 

(z/n)(n(mi) | n{m2) \ n{x).0 \ n{x).0) 

will not even discover whether mi = m2. (For this example, we drop the 
implicit assumption that mi and m2 are different names.) On the other 
hand, suppose that we translate this process to: 



' c({mi}„) I c({m2}„) I 

c{y).case y of in 0 
y c{y).case y of {x}„ in 0 



An observer of this process can tell whether mi = m2, even without knowing 
mi or m2 (or n). In particular, the observer may execute: 

c{x).c{y).{[x is y] d{) \ c{x) \ c{y)) 
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This process reads and relays two messages on the channel c, and emits 
a message on the channel d if the two messages are equal. It therefore 
distinguishes whether mi = m2- The importance of this sort of leak depends 
on circumstances. In an extreme case, one cleartext may have been guessed 
(for example, the cleartext "attack at dawn"); knowing that another message 
contains the same cleartext may then be significant. 

A simple countermeasure consists in including a different confounder 
component in each encrypted message. In this example, the implementation 
would become: 



The names pi and p2 are used only to differentiate the two messages being 
transmitted. Their inclusion in those messages ensures that a comparison 
on ciphertexts does not reveal an equality of cleartexts. 

Lack of forward secrecy 

As a final example, we consider the pi calculus process: 



This process transmits the name m on the channel n, which is private until 
this point. Then it releases n by sending it on the public channel p. Other 
processes may use n afterwards, but cannot recover the contents of the first 
message sent on n. Therefore, this process is equivalent to 



for any m' . Interestingly, this example relies crucially on scope extrusion, a 
feature of the pi calculus not present in simpler calculi such as CCS [Mil89] . 
A spi calculus implementation of {un){n{m) \ n{x).p{n)) might be: 



However, this implementation lacks the forward-secrecy property [DvOW92] : 
the disclosure of the key n compromises all data previously sent under n. 

More precisely, a process may read messages on c and remember them, ob- 
tain n by decrypting {n}p, then use n for decrypting older messages on c. 
In particular, the spi calculus process 

c{x).{c{x) I c{y).case y of {z}p in case x of {w^z in- diw)) 




{vn){n{rn) \ n{x).p{n)) 



{vn){n{m') \ n{x).p{n)) 



{vn){c{{m}n) I c{y).case y of {x}n in c{{n}p)) 
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may read and relay {m}„, read and decrypt {n}p, then go back to obtain 

m from {m}„, and finally release m on the public channel d. 

Full abstraction is lost, as with the other attacks; in this case, however, 
it seems much harder to recover. Several solutions may be considered. 

• We may restrict the pi calculus somehow, ruling out troublesome cases 
of scope extrusion. It is not immediately clear whether enough expres- 
siveness for practical programming can be retained. 

• We may add some constructs to the pi calculus, for example a construct 
that given the name n of a channel will yield all previous messages 
sent on the channel n. The addition of this construct will destroy the 
source-language equivalence that was not preserved by the translation. 
On the other hand, this construct seems fairly artificial. 

• We may somehow indicate that source-language equivalences should 
not be taken too seriously. In particular, we may reveal some aspects 
of the implementation, warning that forward secrecy may not hold. 
We may also specify which source-language properties are maintained 
in the implementation. This solution is perhaps the most realistic one, 
although we do not yet know how to write the necessary specifications 
in a precise and manageable form. 

• Finally, we may try to strengthen the implementation. For example, 
we may vary the key that corresponds to a pi calculus channel by, at 
each instant, computing a new key by hashing the previous one. This 
approach is fairly elaborate and expensive. 

The problem of forward secrecy may be neatly avoided by shifting from 
the pi calculus to the join calculus [FG96] . The join calculus separates the 
capabilities for sending and receiving on a channel, and forbids the commu- 
nication of the latter capability. Because of this asymmetry, the join calculus 
is somewhat easier to map to a lower-level calculus with cryptographic con- 
structs. This mapping is the subject of current work [AFG98]; although still 
impractical, the translation obtained is fully abstract. 

4 Full Abstraction in Context 

With progress on security infrastructures and techniques, it may become 
less important for translations to approximate full abstraction. Instead, we 
may rely on the intrinsic security properties of target-language code and on 
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digital signatures on this code. We may also rely on the security properties 
of source-language code, but only when a precise specification asserts that 
translation preserves those properties. Unfortunately, several caveats apply. 

• The intrinsic security properties of target-language code may be ex- 
tremely hard to discover a posteriori. Languages such as JVML are 
not designed for ease of reading. Furthermore, the proof of those prop- 
erties may require the analysis of delicate and complex cryptographic 
protocols. Certifying compilers [NL97, MWCG98] may alleviate these 
problems but may not fully solve them. 

• Digital signatures complement static analyses but do not obviate them. 

In particular, digital signatures cannot protect against incompetence 
or against misplaced trust. Moreover, digital signatures do not seem 
applicable in all settings. For example, digital signatures on spi calcu- 
lus processes would be of httle use, since these processes never migrate 
from one machine to another. 

• Finally, wc still have only a limited understanding of how to specify 
and prove that a translation preserves particular security properties. 
This question deserves further attention. It may be worthwhile to ad- 
dress it first in special cases, for example for information-flow proper- 
ties [Den82] as captured in type systems [VIS96, Aba97, ML97, HR98]. 

The judicious use of abstractions can contribute to simplicity, and thus to 
security. On the other hand, abstractions and their translations can give rise 
to complications, subtleties, and ultimately to security flaws. As Lampson 
wrote [Lam83] , "neither abstraction nor simplicity is a substitute for getting 
it right". Concepts such as full abstraction should help in getting it right. 
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